在引用資料來源的時候，除了上傳csv的選項，另外一個就是BigQuery。

早在開始摸索ML之前，Google的人員就無數次跟我們推薦BigQuery，只是一直覺得沒有應用的場景。

那麼如果是處理表格式的資料，或許先將資料整理寫進BigQuery裡面，也是一種選擇，搭配Vertex就變成另外的組合技。

因此我們也對於BigQuery的收費方式和適用性稍微評估了一下：

1. 儲存空間的價格相對非常便宜，比起在GCE開VM，外掛硬碟空間的做法相比，還是相對便宜。
2. 但任何查詢的流量都需要收費，譬如說連join的數量也是要算錢，那麼也就是說query的技巧和切partition之類的設置，會大幅影響這部分的費用。
3. 由於可設置的部分和DB提供改調整參數的項目，沒有自己像在VM完全自己弄那麼彈性，無法應付客製化的需求，因此不被考慮了。但是如果只是為了跑ML，單純當作資料儲存的地方，是可以考慮使用的。
4. 資料在存入BigQuery之前，必須要先開好schema，也就是說BigQuery個很制式化的儲存格式，而log類型的資料本身屬於彈性，且欄位不定的資料，除非願意投入事先整理的成本，不然不適用log資料隨便亂塞的需求。

除了報表類型的資料，我們大部分系統的行為和紀錄會在ELK log，ELK本身已經提供很好的資料儲存和查詢的便利性，BigQuery的角色就相對有點雞肋。不過若未來在做更進階一點的題目，或許經過資料的整合，BigQuery還是可以當作考慮的存放選項。

另外值得一提的一點，研究Vertex的期間，我們意外的發現BigQuery還有一個BigQuery ML的功能。

這也是表格式資料相比其他資料類型的ML可以運用的方式。

參考資料

雖然尚未親自試用，看起來十分有趣，Google的策略給人感覺起來，想打造出一個各產品結合的生態系。